Application server systems provide an environment that allows client applications to implement services over a server network. The application server network may include vendor resources for providing services to the client applications. One such application server system is Web Logic Server, provided by BEA Systems of San Jose, Calif.
As vendor resources and application server utilities are used by client applications, it is often necessary to introduce adapters or proxies to mediate requests between clients and application server resources. A proxy is a class that has the same interface as some other class that it is taking the place of. An adapter takes the place of some class and exposes it through a different interface. A typical application server system implements a large number of proxies as resources are invoked and other services are performed. Many of these proxies require substantial amounts of code while often utilized for limited periods of time. Thus, it is not desirable to implement the interfaces for the lifetime of the application server system.
In some systems, a client may need to invoke a method on an Enterprise Java Bean (EJB) that resides on the same virtual machine. A prior art system 100 that illustrates a typical system for handling this operation is shown in FIG. 1. FIG. 1 includes a virtual machine 110 that includes a client or caller 120 and an EJB 130. Client 120 includes stub 150. EJB 130 includes at least one method 140 and skeleton 160. In prior art systems as that shown, client 120 may invoke a method 140 on an EJB 130. Typically, the invocation request is received by a stub 150. The stub then provides the request to the EJB. When method 140 takes parameters, the EJB specification requires that the EJB be invoked using call by value symantics. Thus, a copy of the parameter must be made and passed to the EJB for the EJB method to process. These call-by-value semantics are required by EJB specifications.
One method of the prior art for complying with call-by-value semantics is illustrated in method 200 of FIG. 2. Method 200 begins with start step 205. Next, parameters are retrieved in step 210. The parameters retrieved are those required to be passed to the EJB method to be called by the client. The parameters to be passed are then marshalled into a byte array at step 220. Typically, the parameters are marshalled by a stub. The stub itself is typically generated by a command-line code generation tool. The marshalling is accomplished using Java Object Serialization techniques known to those skilled in the art. The byte array is then provided to an EJB skeleton at step 230. The skeleton then processes the byte array and unmarshalls the array at step 240. In this step, java object deserialization is used to deserialize the objects of the array. Operation of method 200 then ends at step 245. Thus, the key point is that marshalling and unmarshalling from the byte array is expensive in time and processing power. In this manner, the process of method 200 is expensive in time and processing power.
What is needed is a more efficient system and method for implementing call-by-value semantics between an EJB and an EJB method invoking client.